Recent discussion of application architectures has centered around “Service Oriented Architectures”. In service oriented architectures, applications are structured as an application-specific portion and a set of reusable “services”. The application-specific portion typically contains the user interface and the application logic. The services are typically invoked via remote procedure calls (RPCs). Service oriented architectures are particularly prevalent in applications following the “Web 2.0” paradigm.
One problem with many service oriented architectures known in the art is that the application programming interfaces (APIs) to the reusable services tend to be very “brittle”. Brittle means that the usage of and the parameters passed to the service APIs must conform exactly to the specification of the APIs. Therefore, an application programmer must understand the semantics of the service API. The programmer must typically invoke the API with parameters of the correct number, order and type. In practice, this requirement leads to a large number of programming errors resulting from programmers misunderstanding the API. Additionally, significant amounts of time are frequently required to read the API specifications to determine the correct semantics for the API invocations. (In practice, many programmers omit this step, leading to a further increased rate of programming errors.)
Known solutions to this problem of brittle service APIs include the use of Integrated Development Environments (IDEs) such as Eclipse™. Eclipse is a trademark of Eclipse Foundation, Inc., Ottawa, Canada. IDEs known in the art can typically detect and report certain forms of incorrect service API usage. Unfortunately, such checking is typically limited to simple mistakes such as the usage of parameters that are not of the type required by the API. IDEs typically cannot detect errors caused by an incorrect understanding of the APIs semantics. Specifically, IDEs generally cannot detect whether the value of a parameter passed to the service is correct. This is especially true when parameters are passed at runtime because the IDE may not have access to the parameter values at all in such cases.
Furthermore, loosely or dynamically typed programming languages such as JavaScript™, PHP and Python® are increasing in popularity. JavaScript is a trademark of Sun Microsystems, Inc., Santa Clara, Calif., United States, in the United States or other countries. Python is a registered trademark of the Python Software Foundation, Hampton, N.H., United States. For loosely or dynamically typed languages, IDEs generally cannot verify that parameter types are correct. This indicates that IDEs will become less capable of detecting incorrect usage of a service API.
Another approach to the problem of brittle service APIs is to “configure” the service to use certain default parameter values or certain sets of profile-based parameter values. The service is explicitly configured, to a greater or lesser extent, in a separate “configuration” phase before the service is actually used. This beneficially reduces the number of parameters that must be passed to the service API and the number of API invocations that must be performed by the user of the service. This approach is used by so-called “application configuration wizards” such as MySQL® Server Instance Configuration Wizard. MySQL is a registered trademark of MySQL AB, Uppsala, Sweden in the United States, the European Union and other countries.
A notable problem with this approach is that services are frequently configured and invoked by different people. Therefore, the people configuring a service frequently cannot do so effectively because they have insufficient knowledge of how the service will ultimately be invoked. Furthermore, in services known in the art, such configuration is typically performed before the service is invoked. Thus, the configuration process cannot utilize beneficial information which is only obtained when the service is invoked, such as the history of the API's usage in a specific environment.
Other approaches to the problem of brittle service APIs comprise interacting with users of the service to get information that may improve the service delivered to the user. The idea is that the user may be the person best qualified to specify the set of parameter values that must be passed to the service API. For example, users of the Google™ search service are familiar with the service suggesting, in response to the user's search parameters, that the user may have intended to supply a similar, but different, search parameter. Google is a trademark of Google Inc., Mountain View, Calif., United States. The user can then adopt the service's suggestion and reinvoke the service using the revised set of parameters.
However, a notable disadvantage of these approaches is that they require the service to first complete a service request before interacting with the user to configure a subsequent service request. In certain cases, such as when a service request may take a long time to complete or when completing the service request may cause damage that is difficult to reverse, completing the service request before interacting with the user is clearly disadvantageous.